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(54) Multimedia multipoint telecommunications reservation systems 



(57) Reservation controllers and reservation sys- 
tems for reservation of access to multimedia multipoint 
telecommunications servers (MCUs) are provided. The 
reservation controller establishes a reservation domain 
having a reservation request channel on which reserva- 
tion applications may be taken. An ongoing reservation 
conference is associated with the reservation domain. 
The reservation domain is preferably established within 
the rnj-T T.120 standard series requirements, with 
multipoint connection under T.122/T.125, and interface 
to profiles such as ISDN, TCP/IP. X.25, ATM, Ethernet, 
etc., under T.123. A user makes reservations for MCU 
resources by knowing the address of the reservation 
domain, attaching himself to the reservation domain, 
joining the reservation conference via establishing one 
or more transport connections, and sending the reser- 
vation request onto the reservation request channel. All 
reservation requests forwarded onto the reservation 
request channel are received and acted upon by the 
reservation controller. Reservation systems utilizing a 
plurality of reservation controllers are also disclosed, 
where the reservation controllers are part of the same 
domain, are arranged in multiple domains on a single 
level, or are arranged in hierarchical domains. Where 
more than one reservation domain is established, 
same-level or hierarchical level bridges are established. 
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Description 

BACKGROUND 

1 . Field of the Invention s 

The present invention relates broadly to multipoint 
multimedia telecommunications systems. More particu- 
larly, the present invention relates to reservation sys- 
tems for the use of multimedia multipoint servers which w 
are used in the establishment and conduct of multipoint 
multimedia conferences. 

2. State of the Art 

15 

With the increase of throughput (data rate) availa- 
ble in the telecommunications industry, and in associa- 
tion with the improvement of compression and 
decompression algorithms, the number of telecommuni- 
cation applications available to individuals and busi- 20 
nesses has increased dramatically. One of these 
applications is called "multimedia communications* 
which permits video, audio, and in some cases other 
data to be transported from one party to another or oth- 
ers. Multimedia communications can be utilized for a 25 
number of applications, and in different configurations. 
One configuration of recent interest has been multime- 
dia conferencing, where several parties can communi- 
cate in a conference style. 

In multimedia conferencing, the audio and video 30 
data is handled such that each party can see and hear 
one, several, or all of the other parties. In fact, various 
telecommunications recommendations and standards 
are presently being adopted by the ITU-T, ISO, and Bell- 
core which govern the protocols of multimedia confer- 35 
encing (see, e.g., ITU-T T.120). In the multimedia 
conferencing systems of the art (as represented by prior 
art Figure 1), the audio, video, and other data streams 
generated by a user's system 12a are multiplexed 
together directly in the encoder section of a multimedia 40 
encoder/decoder (codec) 14 located at the source/ter- 
minal 16, and transported together through the trans- 
port network 20 (now proposed in ATM format) to a 
similar "peer" codec at a remote location. The peer 
codec is either another codec 1 4 at the remote user site 45 
for a point-to-point conference, and/or a codec/switch 
24 at a multimedia bridge 26 (also called a multipoint 
control unit or MCU) for a multipoint conference. The 
multipoint control unit 26, which typically includes a 
codec/switch 24 and a controller 28, provides confer- so 
ence control (e.g., it determines the signal to be sent to 
each participant), audio mixing (bridging) and multicast- 
ing, audio level detection for conference control, video 
switching, video mixing (e.g.. a quad split, or "continu- 
ous presence device" which combines multiple images 55 
for display together) when available and/or desirable, 
and video multicasting. The audio and video data exit- 
ing the MCU is multiplexed, and continues through the 
transport network 20 to the desired multimedia source 



terminals 12b. 12c. 

It will be appreciated by those skilled in the art that 
the MCU is a technically complex and expensive piece 
of equipment/system, and that use of the MCU is care- 
fully controlled and billed to the user. In addition, it will 
be appreciated that because of its expense and limited 
availability, access to the MCU is treated as a rare 
resource. Thus, in order to guarantee to a given user the 
necessary resources for a desired conference at a given 
time, the user must reserve access to the MCU in 
advance of use. Reservations are made by a "reserva- 
tion request" which typically involves a telephone call to 
an operator at the company with the MCU. In response 
to a reservation request which will often include param- 
eters such as a starting time, a duration, and resources 
necessary (e.g., bandwidth, mixing and switching, etc.), 
the operator will typically access a "reservation control- 
ler", which is typically a programmed computer, in order 
to determine whether the required resources of the 
MCU will be available at the^Jesired time. If the 
resources are available, the operator will enter informa- 
tion into the reservation controller program related to 
the incoming request for desired connections and serv- 
ices for the given time, accept the reservation, and 
inform the applicant/user of codes (e.g., a reservation 
number) required for the conference. When the time is 
reached for the conference, the reservation controller 
will inform the MCU of the beginning of a new confer- 
ence and the precise resources reserved for that confer- 
ence. When the users wish to join the conference and 
access the MCU, the users call the operator, provide the 
reservation number, and are added to the conference, 
with the necessary resources having been already 
reserved and available. 

To date, the use of MCU's has been very limited. 
There are several reasons for this limited use. First, all 
multimedia services are extremely new, and most tele- 
communications customers have not yet invested in 
multimedia service equipment. It is expected, however, 
that the next five years will see an explosion of growth in 
the area of multimedia telecommunications. Second, 
the companies which provides multimedia equipment 
often utilize proprietary or alternative standardized 
schemes (e.g., MPEG and JPEG) which are not neces- 
sary compatible. Thus, it is often impossible for owners 
of different types of multimedia equipment to communi- 
cate with each other. Again, solutions to this problem 
are being proposed, including transcoders which are 
intended to make MPEG and JPEG equipment compat- 
ible. Third, and with respect to multipoint multimedia 
services such as conferencing, each manufacturer of an 
MCU uses its own proprietary reservation controller 
mechanism for reserving access to the MCU. Thus, 
unless each user in the conference has access to the 
same MCU, or to MCUs which are under control of the 
same reservation controller, it may be impossible for 
users to conference as desired because reservations 
requiring access to different MCUs may be impossible 
because of their control by different controllers. 
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SUMMARY OF THE INVENTION 

It is therefore an object of the invention to provide a 
reservation controller for multimedia multipoint servers. 

It is another object of the invention to provide a s 
standardized reservation system which will permit an/ 
multimedia user to reserve the resources of one or more 
MCUs for a multimedia multipoint conference. 

It is a further object of the invention to provide a res- 
ervation system for multimedia multipoint servers which 10 
utilizes the environment ol the T.I 20 protocol series in 
receiving a reservation request. 

It is an additional object of the invention to provide 
a multimedia multipoint server reservation system 
which has an established reservation domain which is 
includes one or more reservation controllers and to 
which a user can attach in order to place a reservation 
application. 

Another object of the invention is to provide an 
automatic multimedia multipoint reservation system. 20 

A further object of the invention is to provide a mul- 
timedia multipoint server reservation system with multi- 
ple reservation controllers arranged in a hierarchical 
multiple domain structure. 

An additional object of the invention is to provide a 25 
reservation domain having a reservation request chan- 
nel utilized by multiple reservation controllers of a mufti- 
media multipoint server reservation system. 

Yet another object of the invention is to provide a 
server reservation system for multimedia multipoint 30 
communications with multiple reservation domains hav- 
ing continuous and/or dynamic connections. 

In accord with the objects of the invention, and 
according to a first primary aspect of the invention, a 
reservation controller for use with one or more murtime- 35 
dia multipoint servers (MCUs) is provided where the 
reservation controller establishes a reservation domain 
with a reservation request channel on which reservation 
applications may be taken. In the preferred embodi- 
ment, the reservation domain is established within the 40 
T.120 standard series requirements (with the term 
"domain" being defined in ITU-T T.122, and loosely 
defined as including all members who are connected to 
a conference), with multipoint connection under 
T. 1 22/T. 1 25 (Multipoint Communications services) , and 45 
interface to profiles such as ISDN, TCP/IP, PSDN 
(X.25), ATM, IEEE 802.3 (Ethernet) etc., under T.123 
(Transport Protocol Stack Profiles). If desired, confer- 
ence control under T 1 24 (Generic Conference Control) 
may also be provided, although other conference con- so 
trol mechanisms can be utilized. In accord with the 
invention, and based on the T.120 series of standards, a 
reservation "domain" with a reservation request channel 
is established within T.1 22/T. 125 by the reservation con- 
troller in order to collect point-to-point transport connec- ss 
tions and combine them to form a multipoint connection. 
An ongoing reservation conference is associated with 
the reservation domain. If the reservation controller 
establishes a reservation conference under T.1 24, the 



reservation domain is set up as part of the reservation 
conference. 

When users wish to make reservations for 
resources of the multimedia multipoint server, they must 
know the address of the reservation domain, and must 
attach themselves to the reservation domain (the term 
"attach" also being defined in T.1 22) and join the reser- 
vation conference. Typically, this will be accomplished 
by establishing one or more transport connections (as 
defined by ITU-T standards X.214 and X.224 which are 
hereby incorporated by reference in their entirety 
herein) between the user and the reservation controller. 
The transport connection could be established either 
utilizing X.214 and X.224, or via the use of other proto- 
cols such as X.25, TCP/IP, ATM, etc., many of which are 
defined in ITU-T T.123. At the lower layers, any type of 
protocol can be used such as Ethernet, ISDN, PPP, 
etc.) Once attached to the reservation domain, the user 
can make a reservation request by sending the reserva- 
tion request onto the resecwation request channel. All 
reservation requests forwarded onto the reservation 
request channel are received and acted upon by the 
reservation controller. The reservation controller is cou- 
pled to one or more MCUs and preferably stores the 
schedules of the MCUs to which it is coupled so that it 
can properly act on the reservation request. 

In the situation where multiple reservation control- 
lers are provided, as discussed below, the user calls the 
address domain of the "local" reservation controller in 
order to attach to the reservation domain and join the 
reservation conference. Once joined to the reservation 
conference, the user can then send the reservation 
request onto the reservation request channel of the res- 
ervation domain. By utilizing the reservation request 
channel, when a reservation request which affects 
MCUs of different reservation controllers is placed on 
the channel, each affected reservation controller can 
determine whether the MCU or MCUs for which it is 
responsible is/are available as requested. Preferably, 
the resulting determination of each controller is pro- 
vided to the reservation controller of the MCU most local 
to the user for processing and forwarding to the user. 
Alternatively, each reservation controller can send infor- 
mation regarding the availability of its MCUs to the user. 

In accord with a second primary aspect of the 
invention, a reservation system is provided and includes 
a first plurality of reservation controllers which are par- 
ties to a first reservation domain; i.e., the reservation 
controllers are all coupled to a first reservation request 
channel. The reservation system may be further 
expanded by including a second plurality of reservation 
controllers which are parties to a second reservation 
domain, where one or more reservation controllers can 
act as a bridge between the different domains. The 
bridge or connection between the domains can be static 
(continuous), or dynamic (connected intermittently on 
an as-needed basis). If desired, the reservation 
domains may be hierarchical; i.e., providing different 
levels. Thus, the reservation domains may parallel the 
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local/regional/national/international telephone system, 
with first level domains relating to local MCUs, second 
level domains relating to regions (e.g., within a single 
area code); third level domains relating to countries; 
and fourth level domains relating to international confer- 
ences. The connections between the hierarchical 
domains can likewise be static or dynamic. It should 
also be appreciated that regardless of how the reserva- 
tion domains of the reservation system are connected, 
and whether or not they are hierarchical, the reservation 
domains which are established are preferably estab- 
lished under the T.120 standard series requirements- 
According to additional preferred aspects of the 
invention, each user receives reservation information 
(e.g., answers to reservation requests) on the user's pri- 
vate channel. Also, besides utilizing a reservation 
requests channel for transmission of reservation appli- 
cations in a multi-reservation controller system, addi- 
tional channels can be provided. For example, one or 
more channels dedicated for the transmission of man- 
agement information between one or multiple reserva- 
tion controllers and their associated MCUs may be 
provided. Likewise, one or more channels used solely 
for the transmission of reservation data amongst the dif- 
ferent controllers may be provided. 

Additional objects and advantages of the invention 
will become apparent to those skilled in the art upon ref- 
erence to the detailed description taken in conjunction 
with the provided figures. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a representation of a multimedia confer- 
encing system of the prior art, including a telecommuni- 
cations network and an MCU. 

Figure 2 is a high level diagram showing a system 
with a plurality of users, a plurality of MCUs, and a plu- 
rality of reservation controllers. 

Figure 2a is a high level diagram showing the sys- 
tem of Figure 2 with the reservation domain and reser- 
vation request channel of the invention. 

Figure 3 is a diagram of the ITU-T T.120 series 
Infrastructure Recommendation modified in accord with 
the invention to show a reservation application. 

Figure 4 is a diagram of a ITU-T T.120 generic 
application model on which the reservation application 
of the invention is based. 

Figure 4 is a diagram of the server part of the reser- 
vation application of the invention. 

Figure 5 is a high level diagram of a single level res- 
ervation system according to the invention. 

Figure 6 is a high level diagram of a hierarchical 
reservation system with multiple levels according to the 
invention. 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENTS 

Turning to Figure 2, a hypothetical telecommunica- 



tions system is shown and includes a plurality of users 
1 12a- 1 121 (typically coupled to the network 20 - see Fig. 
1), a plurality of MCUs 126a-126d (typically located in 
the network), and a plurality of reservation controllers 

s 130a, 130b (typically coupled to and/or located at the 
MCUs). Each reservation controller 130a, 130b, is 
shown coupled to two MCUs, while each MCU is shown 
servicing three users. It will be appreciated by those 
skilled in the art that depending upon its configuration 

10 and the needs of the users, each MCU can service 
many more than three users; and depending upon sim- 
ilar parameters, each reservation controller can service 
more than two MCUs. However, for purposes of simplic- 
ity of understanding, two reservation controllers, four 

/5 MCUs, and twelve users are shown. With the provided 
arrangement, it will be appreciated that if users 112c, 
1 12e, 1 12f, 1 12g ( 1 12h, and 1 12j should wish to partic- 
ipate in a multimedia conference, the services of the 
four different MCUs 126a-126d will be required. Thus, 

20 the two reservation controllers 1 3£a, 1 30b must be con- 
tacted to reserve appropriate access and processing of 
the MCUs. However, with the systems that presently 
exist in the art. if the MCUs and reservation controllers 
are owned and operated by different companies, it may 

25 be impossible to arrange such a multimedia conference. 
In addition, with the provided arrangement it is not evi- 
dent to which reservation controller the user should for- 
ward a reservation request, and how the reservation 
controllers will share the information contained in the 

30 request among themselves. 

As seen in Fig. 2a, and in accord with the invention, 
one of the reservation controllers 130a, 130b of the 
hypothetical telecommunications system of Fig. 2 initi- 
ates and establishes a "reservation domain" which is 

35 provided with (typically upon request) a "reservation 
request channel" 135; and the other of reservation con- 
trollers attaches itself to the established reservation 
domain and joins the reservation request channel 135. 
The reservation domain is associated with a "reserva- 

40 tion conference" (which if desired, may be pursuant to 
ITU-T T.124) and attachment to the reservation domain 
is accomplished by joining the conference. As is defined 
by ITU-T T.122 (MCS), any node (users, reservation 
controllers, MCUs, etc.) which attaches itself to a 

45 domain will be assigned a private channel (also called a 
"single member channel"). The private channel is nor- 
mally used as a user identifier which provides a user 
identification and serves as an address for point-to- 
point communication within the multipoint domain. How- 

so ever, within T.122, another type of channel called a mul- 
ticast channel can be defined to which any number of 
nodes can be joined. The reservation channel 135 is 
such a multicast channel. 

It should be appreciated by those skilled in the art 

55 that any node which is attached to the domain can send 
data on any channel in the domain (the ability to send 
data being shown by dotted Ones in Fig. 2a). However, 
only nodes which have joined a particular channel will 
receive the data sent on that particular channel (the 
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ability to receive data being shown by solid lines in Fig. 
2a). Thus, any node wishing to send private data to any 
other node will do so by sending this data on the private 
channel of the destination node, with representative pri- 
vate channels 1 47c and 147i being shown in Fig. 2a for 5 
users 11 2c and 112L 

A user who wishes to make a reservation will join 
the reservation conference and must attach himself to 
the reservation domain, but will not join the reservation 
request channel. Once attached to the reservation 10 
domain, the user can attempt to place a reservation by 
sending a reservation request onto the reservation 
request channel 135. The reservation request will typi- 
cally include a plurality of multimedia conference 
parameters discussed in more detail below such as the 15 
starting time, the duration, the addresses of the users 
involved, and the resources necessary for the confer- 
ence In addition, the user will specify his own private 
channel address for reservation confirmation. Since the 
reservation controllers 130a, 130b are party to the res- 20 
ervation domain and have joined the reservation 
request channel, the parameters placed on the reserva- 
tion request channel 135 are available to (i.e., are 
received by) the reservation controllers 130a and 130b. 

Where the set of users who will be party to the mul- 2s 
timedia conference all are serviceable by a single MCU 
(such as users 1 12d, 1 12e, and 1 12Q, then the reserva- 
tion controller (eg., 130b) for that single MCU (e.g., 
MCU 1 26b) will make a determination as to whether the 
necessary MCU 1 26b resources will be available for the 30 
requested conference for the time requested. If so, the 
reservation controller 130b will confirm the reservation 
with the conference-initiating user via the private chan- 
nel of the user. Where the set of users who will be party 
to the multimedia conference are not all serviceable by 35 
a single MCU (such as users 112a, 112b, and 112g), 
but a single reservation controller (e.g., controller 130a) 
is involved, again, the reservation controller can deter- 
mine whether resources are available and can confirm 
the reservation with the conference-initiating user via 40 
the private channel of the user. However, where the set 
of users who will be party to the multimedia conference 
are serviced by multiple MCUs which are serviced by 
multiple reservation controllers, (such as users 112c, 
1 12e, and 1 12f), then the reservation controllers) (e.g., 45 
130a. 130b) for the MCUs involved (e.g., MCUs 126a, 
126b) will make determinations as to whether the nec- 
essary resources of the MCU 126a, 126b under their 
control will be available for the requested conference for 
the time requested. so 

Determination as to the availability of MCU 
resources which are governed by multiple reservation 
controllers can be accomplished in several ways. In one 
preferred embodiment where all of the reservation con- 
trollers are joined to the reservation request channel, ss 
and they all receive every reservation request which is 
sent to the channel, each controller is programmed to 
determine the part or parts of the resources requested 
by the user which are' managed by itself. Thus, each 



reservation controller can proceed to process the part of 
the request for which it is responsfcrfe (i.e.. a sub- 
request). After processing their sub-requests, those res- 
ervation controllers which are not the master reserva- 
tion controller (i.e., the master being the most local 
reservation controller to the user) for the request send 
responses to the reservation controller which is the 
master for the request. After reviewing the responses, 
the master informs the user of the acceptance or refusal 
of the request on the private channel of the user, and 
informs the other reservation controllers of the result of 
the request. When a reservation is confirmed, the reser- 
vation controllers involved update their MCU resource 
files. 

In a first alternative approach, rather than having 
each reservation controller respond to the master, each 
reservation controller can directly inform the user of its 
response. The reservation process running at the user's 
terminal would then be used to gather all of the 
responses, so that the usot. could determine whether 
the reservation (or a portion thereof) could be accepted. 
If the resources proved to be suitable, the user would 
place a confirmation on the reservation request chan- 
nel, and the reservation controllers would update their 
MCU resource files accordingly. 

As a second alternative approach, the reservation 
controller responsible to answer the request (i.e., the 
master for the request), can communicate with the other 
reservation controllers) and ask for the status of the 
MCU resources for which they are responsible. Upon 
gathering the information, the master can decide 
whether to accept the reservation or not, inform the user 
of the decision, and inform the other controllers so that 
they can update their MCU resource files if necessary. 

It should be appreciated that besides requesting a 
new reservation, the user will typically have the capabil- 
ity of making other requests. For example, the user 
should be able to view, cancel, and modify a previously 
accepted reservation. Furthermore, the user preferably 
should be able to place queries regarding the availability 
of resources. 

According to the preferred embodiment of the 
invention, the entire reservation system, including the 
reservation domain and the reservation request chan- 
nel are generated in accordance with and comply with 
the ITU-T T.120 series of standards (the latest versions 
of which are all hereby incorporated by reference herein 
in their entirety). T.120 and T.121 define the relationship 
between a T12x application and the remaining T.12x 
recommendations or standards, with 7.120 defining the 
environment, and T.121 defining the Generic Applica- 
tion Model to be used with the applications which use 
T. 122/11 25 (Multipoint Communications Service or 
MCS) and T.124 (Generic Conference Control or GCC). 
Therefore, to be compatible, a "reservation application" 
under T.120 must be built with respect to at least the 
T.120, T.121. and T.122/T.125 recommendations. 
Because audio and video control are not particularly 
pertinent to the reservation application, use of T.124 is 
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optional, although minimal control is required for the 
multipoint application. 

As will be appreciated from Fig. 3, and in accord 
with the T.120 infrastructure recommendations, network 
specific transport protocols are set forth in T.123 which 
permit interface with profiles such as Ethernet (IEEE 
802.3), TCP/IP (the Internet). X.214/X.224, ATM, etc. In 
addition, it should be appreciated that "agents'* can be 
provided which will translate or otherwise transform 
commands and data of other profiles which are not part 
of T 123 so that interface with T.122/T.125 is possible. 

Sitting atop the T123 interface is the MCS 
T122/T125 standard which governs multipoint commu- 
nications. Various multipoint applications can be imple- 
mented utilizing T.122/T.125. It should be appreciated 
that T. 1 22/T. 1 25 is particularly desirable and suitable for 
the reservation application of the invention (shown in 
dotted lines in the applications section of Fig. 3 to indi- 
cate that the reservation application is not yet a stand- 
ard application of the ITU-T), as the reservation 
application of the invention utilizes multipoint communi- 
cations. In addition, as shown in Fig. 3. the GCC T.124 
standard can be provided for conference control, 
although the use of conference control under T.124 is 
not necessary for practicing the invention. If GCC is pro- 
vided, however, a node controller is required for gather- 
ing requests from the applications and sending them to 
the GCC. It is noted that Fig. 3 shows that MCS and 
GCC can support applications using standard applica- 
tion protocols T12x (such as T.126 Still Image and 
T.127 File Transfer), as well as applications using non- 
standard protocols and applications using standard and 
non-standard protocols. 

As will be appreciated by those skilled in the art, 
and as suggested by Figure 4. the T.121 standard 
requires that applications include two parts: a User 
Application (UA), and one or more Application Protocol 
Entities (APEs). An APE is further divided into two ele- 
ments: an Application Resource Manager (ARM), and 
an Application Service Element (ASE). 

The User Application has no direct affect on inter- 
working and thus may be product and platform specific. 
The User Application relies on the services of one or 
more APEs to communicate with peer applications at 
other nodes, and does not directly communicate with 
the MCS (T.122/T125) and the GCC (T.124) shown in 
Fig. 4. According to a preferred embodiment of the 
invention the reservation UA is programmed to include 
the following functionalities: reservation type, address 
list, repeating and periodic conferences, help menu, 
and input validity checking. The reservation type func- 
tionality is a program which permits the user to indicate 
whether a new reservation is being requested, or 
whether a review, change or cancellation of a prior res- 
ervation is being requested. The address list functional- 
ity is a program which permits and/or requires the user 
to enter a list of addresses, write cascaded lists, edit 
address lists on-line, name a list edit a previously made 
list label each address in the list and specify which 



entry in the list will have chairperson/broadcaster con- 
trol. 

The UA can also specify parameters which are to 
be provided by the customer. Among the preferred cus- 

5 tomer-provided parameters are: account billing, number 
of conferees, conference timing, conference setup 
mode, conference mode, conference quality, physical 
channel selection, and video receiving mode. The 
account billing permits the user to enter the calling 

10 number or card number which is to be the billed 
account. The number of conferees who will participate 
in the conference should be fixed at reservation time 
due to resource allocation management, although the 
user should be able to modify this number before or dur- 

15 ing the conference, provided resources are free at the 
MCUs involved. The date, time and duration of the con- 
ference should also be fixed at reservation time due to 
resource management with the duration aJso being 
alterable before or during the conference subject to 

20 resource availability. In conjunction with duration param- 
eter, the user may be able to specify a conference termi- 
nation mode. 

The conference setup mode is the mode used by 
the conferees to join a conference and may specify a 

25 parameter (whether the conference is listed or not) and 
three lists. When the parameter indicates that the con- 
ference is not listed, only the conferees specified in the 
three lists can joint the conference. Otherwise, any con- 
feree with the proper password can join the conference. 

30 The three lists preferably include a list of users that will 
be automatically called when the conference is created, 
a list of customers who have permission to joint the con- 
ference after it is created provided that they have the 
proper password, and a list of customers who have per- 

35 mission once they are conferees to invite other custom- 
ers to joint the conference. Each list can contain data or 
be empty. 

The conference mode should include the four 
known basic modes of voice-activated switching, chair- 

40 person control, broadcast monologue, and broadcast 
dialogue. In addition, if desired, other modes such as 
conferee's choice, automatic control, and subconferenc- 
ing can be supported. In conferee's choice, each con- 
feree can decide whom (s)he wants to see and whom 

45 s(he) wants to hear. In automatic control, the MCU will 
decide what must be seen by whom as well as what 
must be heard. If subconferencing is enabled, two or 
more participants to a conference will be able to initiate 
a "private" conference while they are still members of 

so the initial conference. 

The conference quality parameter provided by the 
user specifies the video and audio qualities (band- 
widths) desired, as well as the bandwidth desired for 
other data. Video quality may be constrained by the 

55 standard (e.g., JPEG or MPEG) being used, as well as 
local resources of the conferees, network capacity, etc. 
Likewise, audio quality may be constrained by the 
standard being used, and the application (audio vs. 
voice). The physical channel selection parameter pro- 
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vided by the user allows the user to specify and identify 
which video terminals will use circuit switching to con- 
nect to the MCU and which video terminals will use pri- 
vate lines to connect the MCU. Finally, the video 
receiving mode permits the user to select whether con- s 
ferees will receive a single video feed (e.g., of trie cur- 
rent speaker) from another conferee, a merged video 
feed (e.g., a quad split or "continuous presence"), or 
multiple video feeds which permits the conferee to indi- 
vidually configure and position the incoming images. 10 

Turning now to the Application Protocol Entities 
(APE) side of the T.1 21 standard requirement, the Appli- 
cation Resource Manager (ARM) of the APE provides 
generic functionality common to all standardized appli- 
cation protocols, while the Application Service Ele- is 
ments (ASEs) provide functionality specific to their 
respective application protocols. As set forth by T.1 21, 
an APE is characterized by the following attributes: a 
single MCS service access point (SAP); a single GCC 
SAP, a single application user ID, a single ARM, a single 20 
ASE, and a node controller SAP. 

The ARM is responsible for managing GCC and 
MCS resources on behalf of the ASEs within the APE. 
The ARM should provide the following services: 
responding to indications from the GCC (e.g., permis- 25 
sion to enroll, invoke); enrolling ASEs with the GCC; 
obtaining handles from the GCC; attaching to an MCS 
domain to obtain a single Application User ID for all 
ASEs within the APE; joining static channels; identifying 
and joining multicast channels using the GCC Registry 30 
and MCS; convening private channels and admitting 
peer ASEs to such channels; joining any private chan- 
nels to which an ASE has been admitted; identifying 
and obtaining tokens from the GCC Registry; deleting 
entries from the registry associated with any multicast 35 
channel it may have convened; invoking peer APEs at 
other nodes; and processing Application Roster reports 
to determine the negotiated Application Capability list 
and identity of peer nodes. 

The ASE provides application protocol specific 40 
functionality to the user application with resources 
obtained by the ARM. Its operation is independent of 
the type and identity of tokens and channels passed to 
it. The User Application should specify the type of 
resources to use, but not the identity of those resources. 45 
The ASE obtains the identity of resources to use from its 
ARM. 

The ASE provides the following services: sending 
and receiving application protocol-specific protocol data 
units (PDUs); grabbing and releasing tokens and deter- so 
mining token status using MCS; responding to GCC 
Conductor Assign and Release indications; issuing 
GCOConductor-Permission-Ask requests through the 
Node Controller; and responding to GCC-Conductor- 
Permission-Grant indications. ss 

According to the preferred embodiment of the 
invention, the reservation application has a protocol 
which is divided into three parts: the user (conferee) 
part which is the part which runs on the user's terminal 
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and allows the user to make a reservation; the MCU 
part which runs at the MCU; and the server part which 
runs at the reservation controller and processes all the 
reservation requests. These three separate parts repre- 
sent a logical division of the protocol and not necessar- 
ily a physical one, as the physical MCU can have both 
the MCU and the server part of the protocol. In other 
words, the MCU and the reservation controller may be 
integrated physically. 

The user part of the reservation application is the 
part that runs on the user's terminal, it allows the user to 
exchange data with the reservation server in order to 
make reservations. The tasks of this part are: to estab- 
lish and maintain a MCS (T.122/T.125) connection via 
T.1 23 with a reservation controller; to accept, code, and 
send reservation requests and parameters of the user 
to the reservation controller via the reservation request 
channel; and to receive results from the reservation 
controller via the user's private channel and display 
them to the user. « 

The MCU part of the reservation application runs 
on the MCU and allows the MCU to communicate with 
the reservation controller to inform it of the status of its 
resources. The tasks of this part are to establish and 
maintain a connection with the reservation controller, 
and to receive and answer requests from the reserva- 
tion controller regarding the status of the resources of 
the MCU and the starting of conferences. 

The server part of the reservation application is'the 
part that runs an the reservation controller which is pref- 
erably embodied as a suitably programmed SUN 
SPARC STATION 5 having suitable memory (although 
other processors, computers, or work stations could be 
utilized). The server part of the reservation application 
which is shown schematically in Fig. 4a allows the con- 
troller to exchange data with the users and the MCUs in 
order to process the different requests of the users/con- 
ferees. The tasks of this server part are to: establish and 
maintain multiple simultaneous MCS connections with 
users, MCUs, and other reservation controllers (via use 
of the application resource manager 170, the MCS 172, 
and if desired, the GCC 174), thereby establishing a 
reservation domain and conference; monitor the status 
of ail MCUs connected to the reservation controller, 
including notifying the MCUs of the start and the 
resources required for a conference (using the resource 
handler 182); receive, process, and accept or refuse the 
requests of the users such as new reservations, modifi- 
cations of reservations, etc. based on any desired 
acceptance algorithm (using the reservation manager 
184 and the acceptance algorithm 186); maintain a list 
of the reservations for which it is responsible (at the res- 
ervation handler 188 of Fig. 4a); and exchange data 
with other reservation controllers when a reservation 
request necessitates the use of more than one reserva- 
tion controller. It will be appreciated by those skilled in 
the art, that the algorithm for accepting or rejecting new 
reservations, or modifications of the reservations can be 
proprietary to the supplier of the reservation controller. 
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Turning now to Fig. 5, a hypothetical system with 
ten reservation controllers 230a-230j, each of which is 
respectively coupled to an MCU 226a-226j and two 
users 212a1-212j2 is seen. The reservation controllers 
of the reservation system of Fig. 5 are structured on a 
single level, in that any reservation controller can con- 
nect itself to any other reservation controller and 
exchange data with it. It should be appreciated, that in 
accordance with the invention, the single level structure 
of the system of Fig. 5 can utilize a single reservation 
domain, or multiple reservation domains. In particular, if 
all of the reservation controllers 230a-230j are attached 
to the same reservation domain, then they will all be 
joined to the same reservation request channel. Thus, 
any reservation request which is placed on the reserva- 
tion request channel will be reviewed by each reserva- 
tion controller of the system for purposes of determining 
whether its resources will be required. On the other 
hand, where numerous reservation controllers are 
being utilized, it might be advantageous to break the 
reservation controllers into more than one domain. In 
this situation, at least one of the reservation controllers 
should act as bridge by being part of two or more reser- 
vation domains. Thus, if a user should wish to establish 
a conference with conferees who would be handled by 
the reservation controller of another domain, the bridge 
controller would pass the reservation request informa- 
tion onto the reservation request channel of the other 
reservation domain so that the appropriate reservation 
controller in the other domain could address the 
request. In Figure 5, a single level, two domain system 
is seen, where reservation controllers 230a-230e are 
part of a first domain, and reservation controllers 230e- 
230j are part of the second domain. Since reservation 
controller 230e is part of both domains, it acts as the 
bridge controller. 

Turning to Figure 6, the same ten reservation con- 
trollers 230a-230j, MCUs 226a-226j, and users 212a1- 
212j2 discussed above with reference to Fig. 5 are 
seen, but they are arranged in a multiple level or hierar- 
chical architecture. In a hierarchical system, multiple 
domains are established. While many different hierar- 
chical systems can be provided, the system of Figure 6 
suggests a preferred approach where each reservation 
controller (with each controller possibly corresponding 
to a plurality of local exchanges) establishes its own res- 
ervation domain with one or more local MCUs and the 
local users. A plurality of second level reservation 
domains (each corresponding, if desired, to an area 
code) are established by providing second level reser- 
vation controllers 330a-330e which share a reservation 
request channel with one or more of the first level reser- 
vation controllers. Thus, as seen in Fig. 6, reservation 
controllers 230a and 230b are confer enced with second 
level controller 330a in a first second level reservation 
domain; reservation controllers 230c and 230d are con- 
ferenced with second level controller 330b in a second 
second level reservation domain; reservation controllers 
230e, 230f , and 230g are conf erenced with second level 



controller 330c in a third second level reservation 
domain; reservation controller 230h is corrferenced with 
second level controller 330d in a fourth second level 
reservation domain; and reservation controllers 230i 
5 and 230j are conferenced with second level controller 
330e in a fifth second level reservation domain. 

A third level reservation domain is shown in Fig. 
6 by the provision of a third level controller 430 which 
conferences with all of the second level reservation con- 
ic trailers 330a-330e. The third level domain can corre- 
spond, if desired, to a country code. It should be 
appreciated that a fourth level (e.g., international) 
domain may also be established. In fact, by hierarchi- 
cally dividing the domains in different manners, it will be 
15 appreciated that many more than four levels can be pro- 
vided. 

The advantage of the hierarchical architecture of 
Fig. 6 over the single level architecture of Fig. 5 is that 
there is no need for a bridging reservation controller to 

20 keep large amounts of information regarding the differ- 
ent systems which it is bridging. Rather, if a reservation 
controller notes a request on the reservation request 
channel of its domain which it cannot handle, it immedi- 
ately passes that information to the reservation control - 

25 ler of the higher domain to which it is also party. 
Depending upon whether or not the information can be 
handled at that level, the reservation controller of the 
higher domain may then either pass the information to 
yet a higher domain, or back down to the appropriate 

30 lower domain. Thus, in the hierarchical architecture, the 
reservation controllers bridge different levels of domain, 
but need not keep detailed information regarding the 
higher domains. 

It should be appreciated by those skilled in the art 

35 that the architectures of Figures 5 and 6 are not neces- 
sarily exclusive of each other. In other words, it is possi- 
ble to use single level bridging reservation controllers as 
part of one or more levels of a hierarchical arrangement. 
It will also be appreciated that the architecture of the 

40 reservation application can be based on either a "con- 
tinuous connection" or a "dynamic connection" type 
arrangement. In the continuous connection arrange- 
ment, all nodes that are concerned by reservations, as 
well as the nodes that might need one time to make a 

45 reservation must be connected continuously to the res- 
ervation domain. The advantage of the continuous con- 
nection arrangement is that MCS connection time is 
minimized. With the dynamic connection arrangement, 
the nodes establish different connections based on their 

so instant needs, with connections being made each time a 
conferee has a reservation request, and connection 
being released once the processing of the request is 
terminated. With the dynamic connection arrangement, 
a connection is created (i.e.. the domain is modified) for 

55 each request, and the connection is deleted (i.e., the 
domain is modified again) when the result of the request 
is known. The advantage of the dynamic connection 
arrangement is that the cost of connection is limited only 
to the time of actual usage. Again, it should be recog- 
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nized that the continuous connection and dynamic con- 
nection arrangements may be co-utilized. For example, 
the domains which include the users may be set up as 
dynamic connection reservation domains, as most 
users will not need continuous type connections and will 5 
find it expensive to keep a connection active when 
nobody is transmitting data. On the other hand, the 
domains which include only reservation controllers (and 
MCUs) may be set up as continuous connection reser- 
vation domains, as large amounts of data may be regu- w 
larly sent, and connection may be required almost 
continuously. If desired, statistical measurements may 
be made of the use of each connection and therefrom a 
decision can be made as to whether the dynamic or the 
continuous connection is most desirable for that con- 15 
nection. In fact, if desired, some connections may be 
continuous during periods of peak usage, and dynamic 
at other times. 

There have been described and illustrated herein 
multimedia multipoint telecommunications reservation 20 
systems. While particular embodiments of the invention 
have been described, it is not intended that the inven- 
tion be limited thereto, as it is intended that the invention 
be as broad in scope as the art will allow and that the 
specification be read likewise. Thus, while the invention 25 
has been described with reference to the ITU-T T.120 
family of standards, it will be appreciated that other plat- 
forms could be utilized provided that a reservation 
domain is established with a reservation request chan- 
nel to which users can connect to make a reservation 30 
request. Likewise, while the invention was described 
with reference to particular arrangements with only one 
or two MCUs coupled to each reservation controller, 
and only two or three users coupled to an MCU. it will be 
appreciated that different numbers of MCUs could be 35 
used in conjunction with a reservation controller, and 
different numbers of users could be coupled to an MCU. 
In fact, pursuant to T.122/T.125, up to 65,535 connec- 
tions can be made in a single domain, although it would 
not be deemed advisable to have so many users con- 40 
nected to a single MCU. Also, while the conference con- 
trol was described with reference to T.124, it will be 
appreciated that since only minimal control is necessary 
for the reservation application (i.e., data only as 
opposed to audio/video/data), other control mecha- 45 
nisms which do not meet T.124 requirements could be 
utilized. It will therefore be appreciated by those skilled 
in the art that yet other modifications could be made to 
the provided invention without deviating from its spirit 
and scope as so claimed. so 

Claims 

1 . A reservation controller for controlling access to at 
least one telecommunications multimedia ss 
multipoint control unit (MCU), comprising: 

a) means complying substantially with ITU-T 
T. 122 multipoint communications service 



(MCS) protocol for establishing with multipoint 
connection a reservation domain with a reser- 
vation request channel; 

b) conference control means associated with 
said reservation domain and establishing an 
ongoing reservation conference; 

c) first interface means complying substantially 
with at least a portion of ITU-T T.123 network 
specific transport protocol for interfacing with a 
data transport profile of a user who wishes to 
make a reservation; 

d) second interface means for coupling said 
reservation controller to the at least one MCU; 

e) reservation application protocol entity 
means including means for receiving a reser- 
vation request placed on said reservation 
request channel, and means for determining 
whether the at least one MCU coupled to said 
reservation controller has sufficient resources 
to meet said reservation request, wherein 

the user makes said reservation request 
by attaching to said reservation domain, joining 
said ongoing reservation conference, and plac- 
ing said reservation request on said reserva- 
tion request channel. 

2. A reservation controller according to claim 1, 
wherein: ♦ T 

said first interface means complies substan- 
tially with all of said ITU-T T.123 network spe- 
cific transport protocol and provide an 1 
X.214/X.224 protocol interface, an IEEE 802.3 
protocol interface, an ATM protocol interface, 
and a TCP/IP protocol interface. 

3. A reservation controller according to claim 1, 
wherein: 

said conference control means complies sub- 
stantially with at least a portion of ITU-T T.124 
generic conference control (GCC) protocol, 
and controls said ongoing reservation confer- 
ence. 

4. A reservation controller according to claim 1, 
wherein: 

said reservation controller is coupled to a plu- 
rality of MCUs, and said reservation application 
protocol entity means includes means for stor- 
ing resource schedules of said plurality of 
MCUs. 

5. A reservation controller according to claim 1, fur- 
ther comprising: 

means for sending a response regarding said 
reservation request to the user via a private 
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channel of the user. 

6. A reservation controller according to claim 1, fur- 
ther comprising: 

5 

means for collecting information from another 
reservation controller. 

7. A reservation controller according to claim 6, 
wherein: 10 

said information is a response by said the other 
reservation controller to a reservation request 
regarding an MCU coupled to the other reser- 
vation controller. 15 

8. A reservation controller according to claim 6, 
wherein: 

said information relates to a resource schedule 20 
of an MCU coupled to the other reservation 
controller. 

9. A reservation system which controls access to a 
plurality of telecommunications multimedia 25 
multipoint control units (MCUs), comprising: 

a) a first reservation controller having 

means for establishing with multipoint con- 30 
nection a first reservation domain with a 
first reservation request channel, 
conference control means associated with 
said first reservation domain and establish- 
ing a first ongoing reservation conference, 35 
first interface means for interfacing with a 
data transport profile of a user wishing to 
make a reservation, 

second interface means for coupling said 
first reservation controller to a first MCU of 40 
the plurality of MCUs the resources of 
which is controlled by said first reservation 
controller, and 

first reservation application protocol entity 
means including first means for receiving a 45 
reservation request placed on said first 
reservation request channel, and means 
for determining whether the first MCU cou- 
pled to said first reservation controller has 
sufficient resources to meet its portion of so 
said reservation request; 

b) a second reservation controller having 

means for joining said first ongoing reser- ss 
vation conference and for coupling to said 
first reservation request channel, wherein 
reservation requests of a user placed on 
said first reservation request channel are 
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available to said second reservation con- 
troller when said second reservation con- 
troller is joined to said first ongoing 
reservation conference, 
third interface means for coupling said sec- 
ond reservation controller to a second 
MCU of the plurality of MCUs the 
resources of which is controlled by said 
second reservation controller, and 
second reservation application protocol 
entity means including second means for 
receiving a reservation request placed on 
said reservation request channel. 

1 0. A reservation system according to claim 9, wherein: 

said second reservation controller has means 
for determining whether the second MCU cou- 
pled to said second reservation controller has 
sufficient resources to meet Hs portion of said 
reservation request, and means for forwarding 
a resource determination to said first reserva- 
tion controller. 

11- A reservation system according to claim 9, wherein: 

said second reservation controller includes 
means for sending information regarding 
resources of said second MCU to said first res- 
ervation controller. 

12. A reservation system according to claim 10, 
wherein: 

said second reservation controller has fourth 
interface means for interfacing with a data 
transport profile of another user wishing to 
make a reservation, 

13. A reservation system according to claim 12, 
wherein: 

said second reservation controller further 
includes means for establishing with multipoint 
connection a second reservation domain with a 
second reservation request channel, and sec- 
ond conference control means associated with 
said second reservation domain and establish- 
ing a second ongoing reservation conference. 

1 4. A reservation system according to claim 9, wherein: 

said second reservation controller further 
includes means for establishing with multipoint 
connection a second reservation domain with a 
second reservation request channel, and sec- 
ond conference control means associated with 
said second reservation domain and establish- 
ing a second ongoing reservation conference. 
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15. A reservation system according to claim 14, further 
comprising: 

a third reservation controller coupled to at least 
one of said first and second reservation 
domains and having, 

second means for joining at least one of 
said first and second ongoing reservation 
conferences and for coupling to at least 
one of said first and second reservation 
request channels, interface means tor cou- 
pling said third reservation controller to a 
third MCU of the plurality of MCUs the 
resources of which is controlled by said 
third reservation controller, and 
third reservation application protocol entity 
means including third means for receiving 
a reservation request placed on one of 
said first and second reservation request 
channels. 



16. 



A reservation 
wherein: 



system according to claim 15, 



vation conference joins said second reserva- 
tion controller to said first ongoing conference 
on an ongoing static basis. 

5 21 . A reservation system according to claim 9, wherein : 



said means for establishing with multipoint con- 
nection a first reservation domain, and said 
means for joining said ongoing first reservation 
conference and for coupling to said first reser- 
vation request channel both" comply substan- 
tially with ITU-T T.122 multipoint 
communications service (MCS) protocol. 



10 



15 



20 



25 



22. A reservation system according to claim 21, 
wherein: 

said first interface means complies substan- 
tially with at least a portion of ITU-T T.123 net- 
work specific transQfirt protocol for interfacing 
with a data transport profile of a user who 
wishes to make a reservation. 



said first reservation domain is at a first hierar- 
chical level, and said second reservation 
domain is at a second hierarchical level. 

17. A reservation system according to claim 16, 30 
wherein: 



said third reservation controller is at one of said 
first and second hierarchical levels. 

18. A reservation system according to claim 16, 
wherein: 



35 



said third reservation controller is at a 1hird 
hierarchical level, and further includes means 40 
for establishing with multipoint connection a 
third reservation domain with a third reserva- 
tion request channel, and third conference con- 
trol means associated with said third 
reservation domain and establishing a third 45 
ongoing reservation conference. 

19. A reservation system according to claim 16, 
wherein: 

50 

said means for joining said first ongoing reser- 
vation conference joins said second reserva- 
tion controller to said first ongoing conference 
on an as-needed baas. 

55 

20. A reservation system according to claim 16, 
wherein: 



said means for joining said first ongoing reser- 
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Abstract 

The Telecommunication Sector of the Internationa! Telecommunication Union (ITU-T) has developed a series of 
recommendations together comprising the H.323 system that provides for multimedia communications in packet-based 
( internetworks. This series of recommendations describe the types and functions of H.323 terminals and other H.323 
devices as well as their interactions. The H.323 series of recommendations includes audio, video and data streams, but an 
H.323 system minimally requires only an audio stream to be supported. Motivated by straightforward interoperability with 
the ISDN and PSTN networks and a variety of other protocols, the recommendation H.323 has been accepted as being the 
standard for IP telephony, developed by the ITU-T and broadly backed by the industry— which is also adopted by both the 
Voice over IP (VoIP) forum and the European Telecommunication Standards Institute (ETSI). This paper presents an 
overview of the H.323 system architecture with all its functional components and protocols and points out all the related 
specifications. <© 1999 Elsevier Science B.V. All rights reserved. 

Keywords: Multimedia communication: Teleconferencing. Internet telephony: CSCW; Computer telephony integration (CTI): Mbone; 
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1. Introduction 

The personal computer and other digital devices 
are rapidly becoming key communication tools for 
millions of users worldwide. The importance of digi- 
tal and data network communications has greatly 
increased with the explosion of the Internet. While 
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electronic mail is still the dominant method of inter- 
active computer communications, electronic confer- 
encing and IP-based telephony are becoming increas- 
ingly attractive. The adoption of packet switching 
and its merging with circuit switching, helps drive 
this communications migration. There are many rea- 
sons for this, among them pricing advantages due to 
improved resource utilization, seamless transitions 
between monomedia and multimedia communica- 
tions, as well as between human-to-computer (e.g. 
web-based) and interpersonal interactions. Additional 
motivations exist such as advanced and flexible fea- 
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tures that may be offered as inherent pan of the 
system (rather than as complex and expensive add- 
ons); and the ultimate integration of voice and data 
networks and systems. Ubiquitous packet based, 
real-time communication offers many challenges: 
with respect to technical complexity and particularly 
in terms of deployment and (organizational) integra- 
tion. One of the key issues related to the success of 
digital and computer communications is a standard 
way of providing connectivity — from call control 
(finding other parties, ringing, etc.) to media encod- 
ing to administrative controls (admission control 
billing etc.). Standards for real-time multimedia 
communications such as H.323 provide the founda- 
tion for global interoperability and thus enable future 
connectivity expansion from a technical as well as 
from an economic point of view. 

For interactive multimedia communications on 
packet-based networks including IP-based telephony, 
the relevant standard of the Telecommunication Sec- 
tor of the International Organization for Standardiza- 
tion (ITU-T) is the H.323 series of recommend- 
ations 2 comprising besides H.323 [4] itself H.225.0 
(core message definitions) [1], H.245 (media channel 
control) [3], H.235 (security framework) [2], H.450.X 
(supplementary services) [6], and H.332 (extensions 
for large group conferences) [5] 3 . The initial version 
of H.323 containing the base functionality for IP- 
based multimedia communications was ratified in 
summer 1996 after one year of intense development 
efforts. This version provided a convergence point 
for the industry and prevented the development of a 
variety of incompatible products on a large scale. 
The H.323 protocol was developed by utilizing or 
taking into account existing technology where possi- 
ble and appropriate: RTP/RTCP, and standard 
codecs were re-used without change; H.323 and 



" In ITU-T language, the H.323 siandard is formally referred to 
as a Reconwietulati<m. 

Work is continuing and new functionality is being added as 

new recommendations or additions to existing ones— while this 
article is being prepared. These additions comprise funher supple- 
mentary services, definition of Management Informalion Bases 
(MIBA operation of H.323-based facsimile systems among manv 
other enhancements. As those arc not mature at the time of writing 
they cannot be addressed in this article. 



H.245 were enhanced to include hooks to make use 
of existing means for achieving Quality of Service 
(QoS) 4 . Only where no applicable solutions existed, 
new protocols were developed. In essence, this ap- 
plies only to policy control and management func- 
tionality; allowing network administrators to control 
(network) resource utilization by H.323 components. 
During the most recent cycle in the ITU-T standard- 
ization, a number of enhancements to H.323 and its 
related protocols resulted in the 1998 version, mani- 
fested as revisions to H.323, H.225.0, and H.245 in 
addition to new related recommendations (H.235, 
H.332, H.450.x). These new features satisfy de- 
mands for new functionality and extensions to exist- 
ing services. Many of them stem from a broadened 
scope with the most important focus — IP telephony 
— motivated by the increased commercial use of 
H.323 for this environment. 

This paper is organized as follows: Sections 2-5 
address the technical foundation based upon the ini- 
tial 1996 recommendations. Section 2 outlines the 
functionality offered by H.323 and presents its archi- 
tecture. Sections 3-5 provide details about the H.323 
system components, its protocols, and the opera- 
tional procedures, respectively. Following this, Sec- 
tion 6 explores the most important extensions of 
H.323 version 2 including enhanced support for IP 
telephony, security functions, and large group con- 
ferences, and also briefly addresses on-going work. 
Section 7 concludes this paper with a brief evalua- 
tion of the status of H.323. 



2. Overview of the H.323 system 

The H.323 series of recommendations describes 
systems, logical components, messages and proce- 
dures that enable real-time, multimedia calls to be 
established between two or more parties on a packet 
network. This section first outlines the services pro- 
vided by a H.323 system and then defines the scope 



4 The H.245 protocol provides QoS capability signaling (in- 
cluding specific parameters from RS VP) and the opening of media 
channels can request RSVP reservation modes in conjunction with 
the RTP streams. Additionally. Appendix II of H.323 presents a 
profile for use with RSVP. 



MSOOCIO: <X P 70031 9A_I_> 



J To S a. J. Ott / Computer Networks 31 (1999) 205-223 



207 



of the H.323 series of recommendations. The latter 
includes a brief introduction to all the system and 
protocol components of H.323 and their purpose in 
the system. 

2.1. H.323 services 

H.323 is designed to extend traditionally circuit- 
based audiovisual and multimedia conferencing ser- 
vices into packet (i.e. IP-based) corporate networks. 
The voice-only subset of H.323 provides the plat- 
form for IP-based telephony. In both areas, seamless 
interoperation with circuit-switched networks (ISDN, 
PSTN) as well as provision of well-known confer- 
encing and PBX services are achieved by H.323; as 
is the straightforward extensibility to include novel 
features. 

The H.323 system aggregates a number of stan- 
dards, which together allow establishing and control- 
ling point-to-point calls as well as multipoint confer- 
ences. Personal computers and other devices — re- 
gardless of the hardware, operating system, and soft- 
ware employed — can inter-operate sharing a rich 
mixture of audio, video, and data across all forms of 



packet-based networks (intranets as well as the Inter- 
net). Seamless interoperation with systems on cir- 
cuit-switched networks is supported via Gateways. 
H.323 provides a tightly controlled communications 
model, with explicit control and media connections 
set up between participants. Media transmission may 
occur point-to-point via unicast or'take advantage of 
multicast capabilities of the underlying networks. 
The selection of available media, their respective 
formats, and the transmission topology are dynami- 
cally negotiated. In addition to interactive multi- 
media conferencing, H.323 also has specific provi- 
sions for other forms of communication — that are 
either special cases and/or may be part of /exten- 
sions to multi-media conferences — , such as multi- 
media streaming, distanee learning, and IP tele- 
phony. As each of these models of communication 
coalesces in a different manner, H.323 enables both 
"join" and '* invite" modes in establishing commu- 
nications. Finally, H.323 defines mechanisms to inte- 
grate directory functions, admission control, and call 
routing that allow implementations (and eventually 
administrators/users) to define virtually arbitrary us- 
age policies for the H.323 environment. 
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2.2. Scope of H. 323 

Although H.323 is minimally defined to operate 
utilizing only peer H.323 terminals, the recommen- 
dation defines a number of additional logical H.323 
elements. These elements include Gatekeepers for 
policy control and address resolution; Multipoint 
Controllers (MCs) and Multipoint Processors (MPs) 
— both of which may be combined to form a Multi- 
point Control Units (MCU)— for multiparty confer- 
encing; as well as Gateways and Proxies for opera- 
tion across network boundaries. The elements are 
defined in terms of specific logical functions and 
protocol responsibilities; there are no preconditions 
on the physical location or combination of elements 
in a network. Although H.323 clearly defines ser- 
vices and interactions between all of these logical 
elements, there are no specific hardware or software 
requirements mandated. Fig. 1 depicts the environ- 
ment of H.323 in terms of the logical system compo- 
nents and also shows a sample network topology 
indicating a variety of interactions covered by H.323 

Fig. 2 illustrates the block diagram of a generic 
H.323 endpoint showing all the core protocols. Con- 



tained within the large light gray block in the center 
are those protocols within the scope of the H.323 
series of recommendations. The darker shaded blocks 
on the left of the figure contain application compo- 
nents that may be different for each implementation. 
On the right side of the figure is" the generic packet 
network interface— while H.323 is defined to allow 
implementation on arbitrary (connectionless) 
packet-switched networks (including DP, IPX, and 
others), only IP networks are of any relevance in 
practice. While definition of the network and trans- 
port protocols themselves are outside the scope of 
the recommendation, H.323 precisely specifies the 
requirements on those protocols: provision of a reli- 
able connection-oriented <(*.g. TCP) along with an 
unreliable connectionless (e.g. UDP) mode of opera- 
tion. For certain functions, H.323 assumes the IP 
multicast service model for the unreliable transport. 
The protocol components indicated by the white 
boxes in Fig. 2 provide: 

- call admission and address resolution mecha- 
nisms, including call routing (admission control 
H.225.0), 

• call establishment and termination (call control 
H.225.0), 




H.323 Scope 

Fig- 2. H.323 core protocols. 
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• capability negotiation and media channel estab- 
lishment (H.245), and 

• runtime media transport and control signalling 
(RTP/RTCP). 

The following section outlines the various logical 
elements of the H.323 system and their respective 
roles. A more detailed description of the H.323 core 
protocols is given in Section 4. Then, Section 5 gives 
an overview of the operation of an H 323 system by 
outlining interactions between H.323 elements and 
the interaction of the various protocols. 

3. H.323 elements 

This section describes the logical elements that 
operate in the H.323 environment [4], Four main 
elements are defined: terminals. Gatekeepers, Gate- 
ways and Multipoint Control Units (consisting of 
Multipoint Controllers and Multipoint Processors). 
An H.323 Proxy is a fifth component that may be 
transparent to H.323 protocol operation; it is not 
explicitly covered in an ITU-T recommendation. The 
synopsis of their function is: 

• Terminal - what humans utilize in a conference 
(e.g. a PC or a phone), 

• Gateway (GW) - bridging to other network envi- 
ronments, 

• Multipoint Controller (MC) - coordinated control 
for multiparty conferences, 

• Multipoint Processor (MP) - audio and video 
mixing or switching, 

• Multipoint Control Unit (MCU) - contains MC, 
MP, and optionally a T.120 MCU, 

• Gatekeeper (GK) - (administrative) control and 
"call routing", and 

• H.323 Proxy - controls how H.323 conferences 
may transit firewalls. 

These H.323 elements are described in more de- 
tail in the remainder of this section. 

3.1. Terminal 

Terminals together with Gateways and MCUs are 
collectively referred to as endpoinls. A terminal is 
typically the one element that exists in all H.323 
usage scenarios. It is the terminal which generates 
and ultimately receives H.323 calls or participates in 



a multi-point conference. This device may be any- 
thing from a simple telephone-like box to a high-end 
computer workstation. All terminals must implement 
audio communications (at minimum, in accordance 
with the mandatory audio codec G.71 1) with support 
for video and data being optional. All terminals must 
implement the H.225.0 call control (derived from 
Q.931) and the H.225.0 admission control (Registra- 
tion, Admission, and Status - RAS) protocols for 
call and conference establishment along with the 
H.245 protocol for capability and media stream con- 
trol. 

5.2. Gateway 

A Gateway provides thTability for H.323 devices 
to interoperate with other devices in heterogeneous 
(e.g. non-H.323-based) network environments. Be- 
sides the underlying network/transport mechanisms 
(e.g. ISDN, PSTN), these environments can also be 
different with respect to the communication proto- 
cols used, the media encoding employed, etc. Conse- 
quently, an H.323 Gateway maps call control proto- 
cols (e.g. Q.931 as found in ISDN to H.225.0), 
control protocols (e.g. H.242 as found in H.320 
systems to H.245), media encoding (e.g. G.711 in 
ISDN to G.723.I), and media serialization (e.g. octet 
framing of ISDN to RTP packetization). H.323 Gate- 
way procedures specify, among many other details, 
how incoming and outgoing calls are to be handled, 
how two-stage dialing works, when call establish- 
ment completes, from which point in time media 
flow is possible, and how a call is terminated. The 
H.323 standard defines a number of Gateway devices 
currently including Gateways for H.320 (ISDN-based 
video conferencing terminals), for H.324 (PSTN- 
based video conferencing terminals), and Plain Old 
Telephone System (POTS,/PSTN) devices. This list 
will expand, as Gateways are developed to bridge to 
other environments. 

3.3. Multipoint control and processing elements 

A Multipoint Control Unit (MCU) provides the 
ability to hold multiparty, multimedia conferences. It 
coordinates all of the media capabilities of the partic- 
ipants and may provide features such as audio mix- 
ing and video selection for endpoints that cannot 
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accomplish this locally as well as transcoding or' 
media streams to bridge between otherwise incom- 
patible endpoints. Furthermore, an MCU may pro- 
vide chair control and conference roster capabilities 
in multi-point conferences. It also facilitates the 
graceful entrance and exit of conference participants. 
In the telephony environment, some PBX supported 
functions of an audio "bridge" might be considered 
analogous to an MCU. H.323 refines the standard 
definition of an MCU drawn from H.320 systems, by 
creating two logical elements: a multi-point con- 
troller (MC) and a multi-point processor (MP). The 
MC provides the call control coordination needed in 
a multi-point conference if the media mixing and 
selection can be performed by the individual partici- 
pants. The MP component provides the audio mix- 
ing, the video mixing or selection, and the handling 
of (T.I20-based [22]) multipoint data communica- 
tions, and may also perform transcoding of media 
streams. 

3.4. Gatekeeper 

Regions of an IP-based network (such as topolos- 
tcally adjacent ones) are grouped into zones for 
administrative purposes. A Gatekeeper administers 
each zone. The Gatekeeper acts as monitor of all 
H.323 calls within its zone on the network and 
provides two main services: call admission and ad- 
dress resolution. 

All endpoints register with their Gatekeeper prior 
to performing any further H.323-related action. An 
H.323 client that wants to place a call, does so with 
the assistance of the Gatekeeper. The Gatekeeper 
provides the address resolution from an alias name 
to a specific transport address of the destination 
client during the initial Admission Request (ARQ) 
signalling. Note that the means the Gatekeeper 
chooses to perform this address translation— lookup 
m its own registration tables, query of directory 
server via the Lightweight Directory Access Protocol 
(LDAPX invocation of any proprietary user location 
protocols, etc.— are deliberately left unspecified in 
H.323. 

During this address resolution phase, the Gate- 
keeper may also make permission decisions based 
upon available bandwidth or any other policy such as 
identity of the caller, or priority of other network 



functions. The Gatekeeper can act as an administra- 
tion point on the network for IT/IS managers to 
control H.323 traffic on and off of the network 
(share of available bandwidth allocated to H.323 
multimedia traffic), utilization of shared resources 
(such as MCUs), or access to "external lines" via 
Gateways. The Gatekeeper may also provide ad- 
vanced features for routing calls to specific Gate- 
ways or extended telephony-like services such as call 
status, call accounting and PBX-like features— a 
prerequisite for this is that the Gatekeeper receives, 
processes, optionally responds to, and/or forwards 
call control messages exchanged between the end- 
points (Gatekeeper-routed call model, refer to Sec- 
tion 5.3). The Gatekeeper is not a required element 
in an H.323 environment, i.e. network administrators 
may choose to run H.323 without a Gatekeeper: but 
in this case, the endpoints must have other means for 
determining the transport address of the other end- 
points) being called. Gatekeepers are required to 
implement the RAS protocot from H.225.0 and may 
optionally implement the H.225.0 call control and 
H.245 protocols if they are to supply advanced ser- 
vices. Services such as call path provisioning (i.e. 
finding an unloaded Gateway) or call manasement 
(i.e. activating an MCU in a call) may be provided in 
this fashion. 

3.5, Proxy 

An H.323 Proxy acts in a manner similar to other 
types of proxies: it acts on behalf of elements on one 
side to contact elements on the other. H.323 Proxies 
must fulfill many of the requirements of an H.323 
Gateway and provide the same interfaces and func- 
tions that a Gateway presents. In practice. H.323 
Proxies are typically co-located with an enterprise 
firewalls or Gatekeepers and monitors all H.323 calls 
between the enterprise and the Internet 5 . The Proxy 



Note that a Proxy operating in an H.323 environment mav 
(but need not) be explicitly detected and used bv an endpoint 
however, protocol exchanges are not modified. Additional ad- 
dressing information may be presented to the Proxv but in 
general, the endpoints do not change their behavior. Some imple- 
mentations place the proxy behind a Gatekeeper thereby insulating 
any H.323 entities from its presence (assuming the Gatekeeper* 
routed call model, see Section 5.3). 
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Fig. 3. H.323 protocol stack. 



ensures that only valid H.323 traffic goes through the 
firewall. It also enforces access control policies for 
users on either side of the Proxy (these are different 
from the bandwidth controls of the Gatekeeper). 
Access control policies may include determining 
which users can initiate or receive H.323 calls, what 
destinations are appropriate, and whether a particular 
user is allowed to use video facilities. 



4. H.323 Protocol components 

Fig. 3 outlines the protocol hierarchies of H.323 
on top of an IP-based network. The shaded elements 
indicate the protocols defined within the scope of 
H.323. The uppermost layer indicates the (applica- 
tion system) functions for which the respective pro- 
tocols are used. Both the H.225.0 call signalling and 
the media control (H.245) depend on a reliable trans- 
port and hence are carried in TCP connections, the 
H.225.0 RAS channel uses UDP as transport layer, 
and the audio/video streams use RTP on top of 
UDP. Real-time media streams may be encoded 
following the ITU standard voice and video codecs 
(G.7xx and H.26x. respectively), using codecs from 
other organizations (e.g. GSM defined by ETSI), or 
proprietary codecs. 

4.1. H.225.0: Call admission and call control 

The H.225.0 document [l] contains the definitions 
of all messages exclusively used by H.323 compo- 
nents and required for basic operation of the H.323 



system; messages shared ^with other H.3xx series 
recommendations (such as H.245 media channel con- 
trol) and messages providing non-core functionality 
(such as H.450.X supplementary services) are speci- 
fied in separate documents (and are discussed subse- 
quently). The H.225.0 document embodies two sub- 
protocols: Registration, Admission, and Status (RAS) 
and the call control messages derived from Q.931 6 
[7], It also includes a normative annex, which de- 
scribes the use of RTP/RTCP in the context of 
H.323. In general, H.225.0 covers the call setup and 
the initial call signalling. 

4.1.1. RAS channel: registration, admission, and sta- 
tus 

The RAS messages are primarily used between 
the endpoints (terminals. Gateways. MCUs) and their 
respective Gatekeepers. RAS comprises a number of 
request/response messages, which facilitate Gate- 
keeper discovery, endpoint registration, and call ac- 
tivity as signalled to a Gatekeeper. After initial 
discovery of and registration with their respective 
Gatekeepers, endpoints use RAS messages to coordi- 
nate activities that may change their utilization of 
Gatekeeper-supervised resources — primarily net- 
work bandwidth and shared equipment such as Gate- 
ways. Endpoints inquire for permission to increase 
resource utilization and provide notifications about 
reduction/termination of resource usage. In addition. 



"Note that references to Q.931 in this article indicate the 
signaling as modified by H.225.0. not the text as referenced in (7j. 
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the Gatekeepers use RAS messages to actively query 
endpoints for their current status (to determine avail- 
ability of Gateways, to detect silent failures of end- 
points, etc.). Thus, the RAS channel puts the Gate- 
keeper in control of its zone of the network and all 
its associated resources thereby allowing access poli- 
cies to be easily defined by the network administra- 
tors. Listed below are the RAS messages defined in 
H.323 version 1 and their intended usage. In general, 
all request messages are of the form xRQ, with the 
confirmation or rejection following the form of xCF 
and xRJ, respectively. 

The RAS messages flow on UDP, thus requiring 
the sequencing and retry mechanisms described in 
H.225.0. (See Table 1.) An identifier called the Call 
Reference Value (CRV) is included in all of the 
RAS PDUs to correlate all of the messages that are 
associated with a particular call. If no Gatekeeper is 
present in the system — which is determined by the 
endpoints when they unsuccessfully attempt to dis- 
cover and register with a Gatekeeper — these mes- 
sages are not utilized. In the absence of a Gatekeeper 
it is assumed that address resolution is gained via 
some mechanism outside the scope of H.323 and that 
some (potentially non-standard) separate entity is 
available to police resource utilization (if any polic- 
ing is needed). 

4.L2. Q.931 -based call signalling channel 

The Q.931 derived messages may look familiar to 
those that understand the ISDN signalling of the 
same name. The Q.931 messages (and procedures) 
have been modified for use by H.323: the meaning 
of the original Q.931 header fields is adapted to 
H.323 and additional H.323-specific information is 



contained in the User-User Information Element 
(UUIE). All of these messages are exchanged on a 
reliable connection which simplifies the error han- 
dling and sequencing at the expense of setting up a 
TCP connection. 

The Q.931 messages provide the signalling of call 
setup requests from caller to callee, intermediate 
signalling (such as indications that a call request is 
being processed further, the other endpoint is "ring- 
ing", etc.) as well as final response(s) from the 
caller back to the caller. Included in the set of final 
response messages are the standard acceptance mes- 
sage, call rejection or redirection indications with 
appropriate reason codes. Additionally the messages 
may include means for the invocation of other sup- 
plementary services known from the telephone world 
(defined in H.450.X, see Section 6 below). In most 
simple call scenarios, once the call connection is 
established, the Q.931 exchanges become dormant 
and the associated TCP connection may be 
closed — unless a supplementary service feature is to 
be invoked later during the call; in this case, the TCP 
connection may also be re-connected by either end- 
point, at the expense of additional signalling and 
latency though. 

4.2. H.245: media and conference control 

H.245 [3] is the media control protocol that H.323 
system utilizes after the call establishment has com- 
pleted. The addressing information required to create 
the separate H.245 protocol channel is passed in the 
call control message during the Q.931 call establish- 
ment phase. H.245 is used to negotiate and establish 



Table 1 

Overview of H.225.0 RAS messages and choir abbreviations 
Message function 



Request 



Gatekeeper discovery 
Endpoint registration 
Call admission 
Media bandwidth control 
Endpoint/gatekeeper location 
Status information 
Disengage From Call 
Message not understood 



Gatekeeper request (GRQ) 
Registration request (RRQ) 
Admission request (ARQ) 
Bandwidth request (BRQ) 
Location request (LRQ) 
Information request (IRQ) 
Disengage request (DRQ) 



Confirmation/response 



Reject 



Gatekeeper confirm (GCF) 
Registration confirm (RCF) 
Admission confirm < ACF) 
Bandwidth confirm (BCF) 
Location confirm (LCF) 
Information response (IRRJ 
Disengage confirm (DCF) 
Unknown message response <XRS) 



Gatekeeper reject <GRJ ) 
Registration reject (RRJ) 
Admission reject (ARJ) 
Bandwidth reject < BRJ) 
Location reject (LRJ) 

Disengage reject (DRJ) 
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all of the media channels carried by RTP/RTCP. 
The H.245 protocol forms the common basis for 
media and conference control for a number of ITU-T 
multimedia communication systems including those 
that operate on a circuit-based transport; thus it 
contains many messages and procedures not used by 
H.323 as well as some extensions specific to H.323. 

The functionality offered by H.245 that is used by 
H.323 falls into four categories, the first three of 
which are mandatory for H.323 operation: 

• Master-slave determination: to provide a means 
for tie-breaking in race conditions and to establish 
an entity (the Multipoint Controller, MC) respon- 
sible for central control in case a call is extended 
to a conference. 

• Capability exchange: used by H.323 elements to 
negotiate a common set of operational capabili- 
ties. The capability sets describe all aspects of 
operation between communicating elements: the 
types of media, number of simultaneous channels, 
maximum bit-rates, and other options. The capa- 
bility exchange may occur at any time during a 
call, allowing for renegotiations of operating 
characteristics (i.e. bandwidth utilization or pro- 
cessing load change). 

• Media channel control: After conference end- 
points have exchanged capabilities, they may open 
and close logical channels of media. Logical 
channels are identifiers used within H.245 as an 
abstraction for media streams. Flow/rate control 
and changing of operating modes along with other 
messages always reference a logical channel. The 
transmitter of media is limited to opening logical 
channels that are within the capability set of the 
receiver. Any audio (and optionally video) are 
logically uni-directional channels. This means 
that each transmitter is required to open a channel 
to the recipient(s). implicitly allowing asymmetric 
use of codecs and different numbers of media 
flows in each direction. Note that this abstraction 
does not mandate that an underlying bi-direc- 
tional transport cannot be utilized. For H.323, a 
single RTP session may account for both logical 
channels (i.e. A to B and B to A) and the concept 
of a logical channel maps directly onto a session 
ID from RTP. Data channels (such as T.120 [22]) 
are typically treated as bi-directional logical chan- 
nels. 



• Conference control: to provide the endpoints 
with mutual awareness in /i-way conferences, 
determine conference-wide suitable capability 
sets, establish the media flow model between all 
the endpoints (which are then initiated by means 
of the media channel control). Conference control 
also provides administrative conference functions 
such as chair control, floor control, and roster 
notification. 

43. Real-time transport protocol 

The Real-time Transport Protocol (RTP) [15] is a 
protocol developed by the IETF (Internet Engineer- 
ing Task Force) to allow transmission of (continu- 
ous) real-time information streams across IP-based 
networks. The Real-time^Transport Protocol consists 
of two parts. RTP defines the common RTP header 
format to be used with real-time data transmission; 
the Real-time Transport Control Protocol (RTCP) 
provides a mechanism for tracking and accounting 
information about the media stream itself and the 
quality of the underlying network— which is 
achieved by some low-bandwidth information ex-1 
change in the background between sendeKs) and 
receiveKs). Both protocols are carried in UDP data- 
grams. 

Traditional circuit-switching networks provide bit 
or byte pipes to carry real-time (isochronous) infor- 
mation streams (such as ISDN or PSTN and the 
related recommendations for video telephony, H.320 
and H.324).Transmission delays of information units 
are constant, implicitly providing intra-stream tim- 
ing; appropriate multiplex protocols on such pipes 
guarantee inter-stream timing as well (e.g. maintain- 
ing the timing relationship between the audio and the 
video stream from a participant to provide lip syn- 
chronization). For packet-based transports such as 
the Internet the situation is different, as are the 
requirements on a transport protocol for real-time 
information. Hence RTP provides the following 
functions: 

- Media streams are not carried bit- or byte- wise; 
rather an information stream is fragmented into 
packets, which are then carried as payloads in 
RTP packets (which in turn are sent as UDP 
packets). Dedicated payload formats define per 
media encoding how the respective information 



8NSOOCID: <XR 700319A_L> 



J. Toga. J. On / Computer Networks 3 1 1 1999) 205-223 



stream is to be split into packets. An RTP header 
field indicates which encoding format is carried 
in the payload of the RTP packet, 
* UDP packets are carried unreliably across an IP 
network: they may be lost, duplicated, and re- 
ordered. The transit delay of UDP packets is 
variable while capture and playback of real-time 
information streams typically is continuous. A 
sequence number and a timestamp in the RTP 
header allow receivers to determine the appropri- 
ate playback point for each information unit 
(packet) received, and thus preserve intra-stream 
timing. Taking into account additional control 
information and feedback from RTCP messages, 
receivers can determine the current inter-arrival 
jitter and derive the correct playback delay there- 
from. RTCP timestamps also allow correlation 
between different media streams to achieve inter- 
stream synchronization. 
• As UDP and IP used underneath RTP already 
provide multiplexing on a per packet basis, no 
separate multiplexing function is needed at the 
RTP layer to distinguish different media streams. 
RTP headers provide a transport-address indepen- 
dent indication of the origin of each RTP packet. 

4.4. Summary of H 32 3 protocol phases 

The activity of the various protocols constituting 
H.323 as described in this section, can be summa- 
rized in a sequence of phases some of which are 



repeatedly entered. Fig. 4 depicts a conceptual phase 
model for the operation of H.323 systems and associ- 
ates certain functions with each of these phases. In a 
simplified model, phases 0 and 1 involve the H.225.0 
RAS protocol that also becomes active during shut- 
down and for each reconfiguration implying changes 
in resource utilization. Phase 2_ comprises H.225.0 
call signalling which may also be involved in phases 
5 and 6. H.245 is active during phases 3 and 5 and is 
also used to terminate a call (phase 6). Media ex- 
change based upon RTP and RTCP is carried out in 
phase 4. 

The following section gives an overview of the 
protocol procedures followed for setting up calls and 
conferences in various modes of operation. 



5. Operating scenarios 

The H.323 protocol specification covers a wide 
range of operating scenarios: simple point-to-point 
calls are included as are multipoint conferences. The 
latter may be created either by ad-hoc expansion of a 
point-to-point call or by using MCUs to host confer- 
ences. Any number of the terminals in a call or 
conference may be located on non-IP-based net- 
works (such as ISDN or PSTN') and be included in 
the H.323 call/conference via dedicated Gateways. 
In all of the aforementioned scenarios. Gatekeepers 
may be involved in address resolution and admission 



Initialization 

Gatekeeper 
admission 

Call signaling 

Negotiation / 
configuration 

Media exchange 

Re-negotiation 

Shutdown 




- initially register with gatekeeper 

• obtain permission from gatekeeper to catt 

- have gatekeeper resolve the address 

- establish call signaling connection to peer 

- call initiation and completion / rejection 

- negotiate systems' roles during the call 

- capability exchange 

- determine mode of operation 

- configure and open logical channels 

- transmit and receive data streams 

- change members, parameters, media, ... 

- terminate the call / conference 

- de-register (if user togs off) 



Fig. 4. HJ23 Protocol phases. 
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control as well as in call signalling and conference 
control. 

In all cases, the involved H.323 components fol- 
low the same overall protocol phases as depicted in 
Fig. 4 above. Phases 0, 1, as well as parts of phase 6 
are only applicable if a Gatekeeper is present in the 
network configuration; phase 5 only applies to calls 
with dynamic encoding changes, invocation of sup- 
plementary services, and to multipoint conferences. 
In the following subsections, the H.323 protocol 
operation for simple point-to-point calls (phases 2. 3, 
4, and part of phase 6) and for multipoint confer- 
ences (involving phases 2 through 5) are described 
as is the principal Gatekeeper operation (phases 0, 1. 
and 6). 

Calls via Gateways to endpoints on other net- 
works are a straightforward extension of point-to- 
point calls, with the Gateway acting as endpoint 
from the H.323 perspective. In such cases, the Gate- 
way translates call signalling, conference control, 
media packetization, and encoding. The basic opera- 
tion is the same as in simple H.323 calls, the map- 
ping and procedural details are beyond the scope of 
this paper and hence are not discussed any further. 

J. /. Point-to-point call establishment 

A simple point-to-point call without a Gatekeeper 
shall serve as a starting point to illustrate the call 
procedures defined by H.323. Assume a scenario 
with two endpoints A and B, with A calling B. Then 
A initiates the call by first making a TCP connection 
to the well known port for H.323 (port 1720) at B's 
IP address; this connection is used to carry all the 
H. 225.0 call signalling messages. A sends a SETUP 
message to B indicating the desire to place a call 
along with various call parameters. B typically first 
responds with an ALERTING message thereby indi- 
cating that the user is being notified ("the phone is 
ringing"), followed by a CONNECT message as 
soon as the user answers. As pan of this exchange, A 
and B also send an ephemeral (dynamic) port num- 
ber to be used for the H.245 connection — which 
may be established at any point in time during or 
after this exchange. After setting up the H.245 con- 
nection, virtually all the protocol activity takes place 
on the H.245 connection. There may be no further 
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reason to use the Q.931 connection, which may be 
closed, but in practice is typically left up. Once the 
audio (and video) codecs and parameters have been 
negotiated, exchanging H.245 OpenLogicalChannel 
messages and the respective acknowledgments cre- 
ates media streams. This sequence passes the trans- 
mitters RTCP address and port number as well as 
the receiver s RTP and RTCP address and port num- 
ber for a particular media stream (for example, audio 
or video). Recall that each channel is logically con- 
sidered to be one way and, therefore, for two ele- 
ments to exchange audio, two logical channels in 
opposite directions need to be opened. An H.323 call 
may be terminated by either endpoint sending an 

H. 245 EndSessionCommand. An H.323 call is also 
terminated when the H.245 control connection is 
lost. 

5.2. Multipoint conferencing with H.323 

Teleconferences — pure audio as well as multime- 
dia — are typically convened in either of two ways: 

I. by ad hoc expansion of a point-to-point call to a 
multipoint conference by adding one or more 
participants; or 

2. by means of pre-planned conference with the 
necessary resources set aside in advance to the 
start of the conference. 

Both modes of operation are supported by H.323 
using the same principal mechanisms for tightly 
coupled conferences 7 . H.323 uses the notion of a 
Multipoint Controller (MC) as the centra] entity that 
coordinates behavior of all the endpoints in a confer- 
ence. The MC is elected during call establishment; 
once in place, the MC role does not change location 
for the duration of the conference. It may be located 
in any of the participating terminals (or Gateways), 
in a Gatekeeper, or in a special-purpose device for 
conferences such as an MCU. 

For expanding a point-to-point call in an ad-hoc 
fashion into a multiparty conference, the entity hold- 



in order to additionally accommodate large-scale conferences, 
a model has been developed that allows co-existence of a tiuhtlv 
controlled core of H.323 participants with an arbitrarily large 
audience which is only loosely-coupled to the conference core. 
This enhancement is described in Section 6.2. 
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ing the MC places an outbound call to the partici- 
pants) to be invited. This invitation may be trig- 
gered by any of the current participants by sending 
an appropriate call-signalling request to the MC. 
Incoming calls received by any of the terminals in a 
call or conference may be redirected to the MC so 
that the calling party can be included in the confer- 
ence as well. 

Pre-planned conferences are based on dedicated 
conferencing devices — e.g. MCUs or special Gate- 
keepers — to "host" the conference. Participants 
connect to such a dedicated device by either directly 
specifying its transport or alias address and then 
naming the conference they want to participate in. 
Alternatively, H.323 supports the notion of confer- 
ence aliases that may be provided to the Gatekeeper, 
which then directs the call to the appropriate MCU. 
All functions of ad-hoc conference expansion to 
bring in additional participants are supported for 
pre-planned conferences as well, and are based upon 
the same mechanisms. 

Independently of the manner by which a confer- 
ence was initiated or where the MC is located, the 
data distribution in an H.323 conference may follow 
two different models: 

• Centralized: the terminals send their 
audio/ video/data streams to an MCU (MP) 
which then performs mixing and/or switching of 
the media streams and redistributes the resulting 
streams: individually to each terminal via unicast 
or commonly to all terminals via multicast. 

• Distributed: each terminal transmits its media 
streams directly to all other terminals which are 
responsible for reception, decoding, and 
mixing/composition of these streams for local 
presentation; the media streams may be dis- 
tributed via multicast to all peers or individually 
to each one via unicast (multi-unicast mode). 

Within a single conference, these modes may 
arbitrarily be combined: different modes may be 
employed for different media, for different end- 
points, etc. 

5, J. Basic model for gatekeeper interaction 

As indicated previously, endpoints are required to 
apply to Gatekeepers before claiming any resources 
in the network environment if they operate in a 
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Gatekeeper-controlled environment. In order to de- 
termine if this is the case, endpoints attempt to 
register with their Gatekeeper. This registration is 
performed in two stages. Initially, the endpoint dis- 
covers a Gatekeeper that is willing to accept its 
registration either by querying a (set of) pre-config- 
ured Gatekeepers) with a GRQ message via unicast 
or multicasting the message to a well-known multi- 
cast address. Secondarily, the endpoint selects one of 
the Gatekeepers willing to accept a registration and 
registers its user aliases, transport addresses for call 
establishment and other parameters with an RRQ 
message. When shutting down, an endpoint de-reg- 
isters from its Gatekeeper by means of a URQ 
message. ^ 

When an endpoint wants to place or answer a call, 
it queries the Gatekeeper by sending an ARQ mes- 
sage. The Gatekeeper accepts it by providing a trans- 
port address for establishment of the call signalling 
channel in the response (ACF); alternatively, the 
Gatekeeper may reject the ARQ by sending an ARJ 
thereby preventing the endpoint from proceeding 
with the call. When in a call, an endpoint may also 
have to contact the Gatekeeper to request changes in 
its resource utilization (via the BRQ message). Upon 
ending a call, an endpoint notifies its Gatekeeper by 
means of a DRQ message. 

When an endpoint asks its Gatekeeper with an 
ARQ for permission to place or answer a call, the 
Gatekeeper may enforce one of two call models 
currently defined in H.323. The Gatekeeper may 
decide to allow the two endpoints to communicate 
directly with one another (direct call model). For the 
caller, this is done by returning the call signalling 
address of the called endpoint, for the callee! this is 
done by simply acknowledging the admission re- 
quest. In this case, the call signaling connection and 
the H.245 connection run directly between the two 
endpoints. Alternatively, the Gatekeeper may keep 
local control over the call (Gatekeeper-routed call 
model) by having the call signaling connection as 
well as the H.245 connection routed through itself. 
On the calling side, this is achieved by returning the 
Gatekeeper s own call signaling address to the caller 
(rather than the remote endpoint's one). On the 
called side, the Gatekeeper explicitly requests a redi- 
rection of the call signaling connection thus requir- 
ing the caller to tear down the call signaling connec- 
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tion and re-establish it to the Gatekeeper of the 
called endpoint. The Gatekeeper-routed call model 
allows the Gatekeeper to keep track of the calls, act 
as an MC and /or provide supplementary and other 
value-added services. 



6. Recent enhancements 

With over a year's worth of commercial develop- 
ment and deployment, IP Telephony has come to the 
forefront as one of the important applications for 
H.323 signaling. A result of this emergence has been 
a number of enhancements to H.323. The highlights 
of these enhancements include: 

• Single roundtrip call connection sequence. In ver- 
sion 2 of H.323 the call establishment sequence is 
shortened by defining a procedure to simultane- 
ously signal capabilities and propose the opening 
of logical channels in a single message to the 
callee. The callee then selects the media channels 
to receive and opens its own channel(s) to the 
caller in a single response. Hence a single call 
signaling message exchange suffices to start me- 
dia streaming in both directions. 

• H.245 Tunneling. H.323v2 allows H.245 mes- 
sages to be carried within call signaling PDUs. 
This allows the TCP connections between entities 
to be reduced, in addition to allowing concurrent 
Q.93 1 and H.245 signaling. 

• Extended addressing/alias types. H.323v2 en- 
hances the variety of aliases that are allowed for 
call establishment. In particular, alias names for 
conferences and URLs are explicitly supported by 
the enhanced scheme (and may be explicitly dis- 
tinguished without textual conventions on the 
alias* contents). 

• Redundant/backup gatekeeper addressing. To 
provide seamless system operation even in the 
event of component failures, H.323v2 allows users 
to register with multiple Gatekeepers (primary 
and backup ones). 

• **Follow-me" destination addressing. The version 
2 Registration messages have been augmented to 
include a sequence of alternative transport ad- 
dresses that might be utilized to contact the end- 
point. A Gatekeeper may provide a list of alter- 
nate endpoints back or the Gatekeeper may mask 



this from the calling endpoint. In either case, the 
extra addresses can be polled to attempt call 
connections. By convention the order of prefer- 
ence is the ordered sequence. 
* User level authentication/authorization. Utilizing 
new H.245 messagesthat were added to support 
the H.235 [2] framework (see next section), appli- 
cations may exchange digital certificates. By issu- 
ing application explicit challenges and requesting 
specific certificate types, the protocol can support 
end-to-end authentication and related authoriza- 
tion. In practice this requires coordination with 
the local implementation to provide interactions 
with a human user (e.g. entering PIN numbers or 
approving of certificate contents). 
These point enhancements along with newer peer 
protocols such as H.235 and H.332 portend to con- 
tinued usefulness in new areas for H.323. The 
H.450.X series of recommendations [6] have been 
derived from the QSIG 8 standards and thus easily 
interface to existing PBX equipment. H.450.1 de- 
fines a framework for extending call control func- 
tions to provide higher level and more complex call 
services. The H.450.X series defines a remote proce- 
dure call scheme and initially describes a small set of 
functions such as call transfer and call forwarding. 
These functions may be provided by endpoints but 
also (similar to PBXs) in dedicated elements such as 
Gatekeepers. The H.450.X services and protocols are 
kept open to allow for easy future expansion by 
standardized as well as vendor-specific services. 

6.L H.235: the H.323 security framework 

As with all communication applications, provision 
of security features is of crucial importance for 
H.323, particularly for global deployment. Designing 
security services for H.323 systems provides a num- 
ber of challenges. Shared, packet networks require 
specialized media privacy to attain the perceived and 
expected protection offered by the circuit networks. 
Typical packet networks are lossy communication 



QSIG is an international standard which defines a signaling 
system in Private Integrated Service Networks (PISN). This is a 
generic term used to describe various types of voice networking 
equipment/services such as PBXs or CENTREXs. 
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environments offering additional challenges for secu- 
rity services. For example media encryption should 
not rely on a stream cipher across multiple RTP 
packets. Finally, limited resources such as Gateways 
or the media content itself must be protected from 
unauthorized use. 

H.235 [2] is one of the newest ITU-T H.323 
related recommendations, officially titled "Security 
and encryption for H series (H.323 and other H.245 
based) multimedia terminals." This recommendation 
provides a general security framework that may be 
incorporated by many multimedia systems including 
H.323. H.235 "describes enhancements within the 
framework of the ITU H.3(XX) specification series, 
to incorporate security services such as Authentica- 
tion and Privacy (data encryption). The proposed 
scheme is applicable to both simple point-to-point 
and multi-point conferences for any terminals which 
utilize H.245 as a control protocol." [2, p. iv] Rec- 
ommendation H.235 describes a number of generic 
messages and procedures, which may be utilized to 
provide all the essential security services for interac- 
tive communications including authentication, pri- 
vacy and integrity. The recommendations H.225.0 
version 2 and H.245 version 3 include the necessary 
message extensions to enable the services described 
in recommendation H.235. 



H.235 encompasses three phases of communica- 
tion: call admission, call establishment and control, 
as well as conference control and media exchange 
(RAS, Q.93K and H.245/RTP, respectively). The 
framework described in H.235, reuses applicable 
protocols that exist such as Transport Layer Security 
(TLS) [8] or Internet Protocol Security (IPSEC)[9- 
14]. During each phase of an H.323 call, the H.235 
security services applied to this phase may be sepa- 
rately negotiated — although the underlying crypto- 
graphic mechanisms are often related. As Fig. 5 
shows, each sequential phase of an H.323 call (indi- 
cated by the "pipes") may be operated with a 
different set of security services enabled. In all cases, 
the type and level of authentication, integrity, and 
confidentiality may be negotiated (either within TLS, 
IPSEC, or explicitly in H.235). 

The following subsections describe the security 
mechanisms available in the respective phases. 

6. LI. Call admission 

RAS signaling between an endpoint and a Gate- 
keeper utilizes UDP and therefore TLS may not be 
used. In many instances, user authentication during 
registration (i.e. input for identification and chal- 
lenges) make IPSEC usage impractical. RAS mes- 
sages with H.235 extensions enable a number of 



Independent Security Contexts 




Call admission 



Call establishment 
and control 



Conference control 
and media exchange 



Fig. 5. Communicaiion phases distinguished by H.235. 
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authentication methods between and endpoint and a 
Gatekeeper. [SO algorithms [18-21] provide the pro- 
cedures for authentication assuming that there is a 
shared secret (e.g. password) or a common public-key 
certificate hierarchy between an endpoint and a 
Gatekeeper. For situations in which there is no shared 
secret, a Diffie/ Hell man exchange may be used to 
establish key material for subsequent encryption or 
signatures. RAS messages may be generated with an 
integrity check value to provide tampering indica- 
tions. There are no standard mechanisms to provide 
for RAS confidentiality (beyond those possibly sup- 
plied by the underlying transport). 

6.L2. Call establishment and control 

Call establishment security services may be pro- 
vided by the underlying transport session, in which 
case no explicit in band signaling is required. The 
well-known port 1300 may be used by H.323 entities 
to establish a Transport Layer Security (TLS) con- 
nection for call establishment and control (Q.931) 
signaling. The call establishment and control phase 
may be protected by TLS, IPSEC or with digital 
certificate technology. These security mechanisms 
may provide authentication, confidentiality and in- 
tegrity, thus specific H.235 signaling may not be 
needed. Authentication is either provided by the 
transport or through a cryptographic link (a signed 
security token) to the authentication which occurred 
during the call admission via H.225.0 RAS before. 
Q.931 messages do not have standard integrity check 
values. During this phase, H.235 security tokens 
may be utilized to provide authorization. 

To provide a policy mechanism for authorization 
(which should be based on appropriate authentica- 
tion) specific tokens are be passed with crypto- 
graphic links to their owners. For example, an IP 
telephony service operator might require a specific 
digital certificate signed by one of its Gatekeepers to 
be presented by a caller anytime a set of Gateways is 
utilized. All of the signaling and payloads required to 
accomplish this (and many more complicated scenar- 
ios) may be invoked within H.235/H. 225.0 during 
the call initiation and establishment phases. 

6.1.3. Conference control and media exchange 

As with the call establishment. H.245 may utilize 
either TLS or IPSEC to provide security services. 



Independent of the operation of H.245, media en- 
cryption algorithms, modes and parameters are com- 
municated by utilizing well-defined identifiers in the 
form of Object Identifier tags. This allows for easy 
implementation of future enhancements to the archi- 
tecture. The identification mechanism also allows the 
full array of publicly known algorithms along with 
any proprietary methods to be signaled in a standard- 
ized, recognizable manner. 

Encryption of media is used within the RTP 
streams to provide reasonable performance and flexi- 
bility in multipoint situations. The session keys that 
are used to encrypt the media may be distributed in a 
number of ways by utilizing H.245 signaling. For 
example, the session key itself may be protected with 
the transient shared secr^ej that the elements estab- 
lished at the beginning of communications or may be 
conveyed to the peer(s) by using public key cryptog- 
raphy. H.235 allows refreshing the session key on 
the fly, thereby enabling *' breaches" in security or 
expulsion from a multipoint conference to be accom- 
plished. 

Facilities for a challenge/response exchange be^ 
tween users and the network and end to end-users 
are provided. Within H.323, these facilities are en- 
abled by H.245 PDU exchanges between peers. 

6.1.4. Operational aspects 

Unlike other aspects of communications, such as 
call control and transport protocols, security technol- 
ogy is significantly influenced by non-technical fac- 
tors. One of these environmental factors that influ- 
enced the development of H.235 will continue to 
impact its deployment: politics. Due to the nature of 
the subject, political issues along international and 
other boundaries, are prominent factors: countries 
limit distribution of (certain types of) security tech- 
nology, ban or constrain its deployment within a 
country, etc. The largest manifestation of these is- 
sues within H.235 is the requirement to negotiate all 
of aspects of security: for example there are no 
requirements for a base level cryptographic algo- 
rithm to be supported. This resulted from the lack of 
international consensus concerning which algorithms 
to employ. Instead of performing the work in the 
ITU-T, it is expected that market segments and/or 
vertical applications will develop fixed * 'profiles'* 
for complete cryptographic interoperability. 
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6.2. H.332: loosely-coupled conferencing with H.323 

The H 332 recommendation [5] extends the tightly 
controlled model of H.323. Where H.323 encounters 
practical limits due to its tightly coupled model 
H.332 provides an architecture and the necessary 
protocols for very large-scale operations. The basic 
conference model that H.332 assumes, is that of a 
panel-style conference: a single presenter or a small 
group of participants (the panel) provide the multi- 
media contents that is distributed to a virtually arbi- 
trarily large audience. As depicted in Fi«. 6, the core 
panel consists of a H.323 conference and is "sur- 
rounded" by a large number of RTP receiving termi- 
nals. These RTP receiving terminals may be H 33^> 
terminals or other RTP/RTCP capable terminals that 
have external means to understand how to connect to 
the conference. 

Establishment of the panel and interactions amona 
its members are tightly controlled using the conven- 
tional control mechanisms of H.323. Administrative 
control of the conference is provided through "social 



protocols" or through H.323 chair- and floor control 
mechanisms. H.323 chair-control gives special privi- 
leges to the conference chairperson and if chair 
control is active, any panel member who wants to 
talk (or send video) must first request the floor from 
the chairperson. Outside the panel, the participants 
are passive; they are essentially receivers who are, 
by default, not allowed to interact. If they wish to 
interact they request join the panel or wait to be 
invited by someone on the panel, just as would occur 
in a conventional H.323 conference. Admission to 
the panel may be determined by some conference 
policy implemented in the MC and/or may be de- 
cided upon by the chairperson on an individual basis. 
The chairperson may also force members to leave 
the panel in order to make room for new ones. 

While the H.323 protocols are re-used to establish 
the panel and change its members, these mechanisms 
for establishing connections and negotiating operat- 
ing modes at the start of a conference are^cumber- 
some and impractical for conferences involving an 
arbitrarily large number of participants. In such cases, 




Fig. 6. Model of an H.332 panel-style conference. 
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the information required to setup a large conference 
must be disseminated well before the start of the 
conference. Large conferences are usually planned 
and pre-announced — examples include presentation 
to a large geographically dispersed audience, dis- 
tance learning, etc. If a conference is pre-announced, 
then the conference modes of operation (such as 
multicast addresses, media capabilities) may also be 
pre-announced to all potential participants thereby 
eliminating the need for negotiation at conference 
startup. 

For the announcing of H.332 conferences and 
their associated parameters, recommendation H.332 
utilizes the format described the Session Description 
Protocol (SDP) [17] developed by the IETF to de- 
scribe conference information. The Session An- 
nouncement Protocol (SAP) [16], web pages. Net- 
news groups, and even email, may be used to convey 
such conference descriptions; the specific manner of 
disseminating this information is outside the scope of 
H.332. The SDP format is enhanced by a few 
H.323-specific attributes including addressing infor- 
mation that allows members of the audience to con- 
tact the MC if they want to join the panel. 

The media exchange/dissemination in an H.332 
conference is accomplished via RTP/RTCP as trans- 
port for audio and video information. The panel may 
operate in any H.323 mode: centralized, decentral- 
ized, or hybrid. Outside the panel, however, multi- 
cast is used for information dissemination in order to 
provide the scalability required for the H.332 confer- 
ence. In addition to H.323 conference control mecha- 
nisms that provide mutual awareness among the 
panel members, RTCP reports are evaluated to ob- 
tain a rough understanding of the conference size 
and the "identities" of its (non-panel) members. 

As with H.323, the support for audio is manda- 
tory in H.332, while video and data are optional. If 
any of the optional media is supported, the ability to 
use a specified common mode of operation is re- 
quired so that all terminals supporting that media 
type can interoperate. H.332 allows more than one 
channel of each type to be in use in the same manner 
as H.323 does. 

For pure audio-visual conferences, the design 
choices of H.323 and H.332— i.e. re-use of existing 
protocols. SDP, SAP, and RTP/RTCP— allow 
seamless interoperability even with non-H.332-capa- 



ble endpoints, the most prominent examples being 
the variety of Mbone conferencing tools available 
today (such as vie [23] and rat [24]). 

6.3. Future work 

While the H.323 series of Recommendations pro- 
vides a sound technical foundation for multimedia 
communication in IP networks including IP tele- 
phony as special case, a variety of (global) infras- 
tructure aspects need to be dealt with accompanying 
the further development of the technical core proto- 
cols. The responsible ITU-T working group as well 
as the ETSI TIPHON project have taken up comple- 
mentary work items towards a further completion of 
the work. As even an outtae of the individual efforts 
are beyond the scope of this paper, the section is 
restricted to very briefly listing the work items cur- 
rently under development: 

On the ITU-T side, current standardization efforts 
include further completion of the supplementary ser- 
vices provided by H.323; improved support for 
trunking (i.e. the use of H.323 in telephony back- 
bones); inter-gatekeeper protocols (for communica- 
tion within as well as across administrative domains); 
support for remote device control; seamless inclusion 
of facsimile transmission utilizing H.323 control; and 
provision of appropriate Management Information 
Bases (MIBs) for H.323 systems and protocols. 

Within ETSI, on-going efforts include the devel- 
opment of a suitable numbering plan for IP tele- 
phony; security profiles for both consumers and ser- 
vice providers. Infrastructure services including 
billing, and accounting mechanisms for a variety of 
call scenarios are further efforts as are work items 
such as coordination of clearinghouse services to 
Quality of Service measurements. 

7. Conclusion 

This paper has provided an overview of H.323 
and its associated recommendations by presenting 
system components, protocols, and modes of opera- 
tion as well as pointing out recent development 
directions. The H.323 system provides a powerful 
and flexible system for lightly controlled, interactive, 
real-time, multimedia communications. The factors 
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that allow the protocols to easily bridge data and 
voice networks also make H.323 scalable. For exam- 
ple, the dynamic exchange of capabilities allows 
communication modes to change during a call if 
needed and adapt to any (changes in) environmental 
or endpoint constraints. Distribution of media pro- 
cessing across different Gateways or MPs contribute 
to scalability and bandwidth or processing flexibility. 
The elements that make up an H.323 network (termi- 
nals. Gateways. Proxies, Gatekeepers, and MCUs) 
enable the deployment of H.323 in a variety of 
physical topologies and operational models. 

Since its early development stages, the H.323 
series of recommendations has gained broad industry 
attention and support. The ongoing product develop- 
ment in the industry on a very broad basis 

including a wide range of communication systems 
from simple point-to-point telephony to rich multi- 
media conference systems— demonstrates this en- 
dorsement. The scale and success of frequent inter- 
operability test events— sponsored by the Interna- 
tional Multimedia Teleconferencing Consortium 
(IMTC) — emphasize the viability of H323 as a 
cross-vendor platform for interactive real-time com- 
munications in IP-based networks. Through perma- 
nent effort by the ITU-T study group responsible for 
H.323. the recommendation continues to be evolved 
and adapted to address new technical issues, match 
new situations, and meet new customer needs. Par- 
ticularly with last year's unparalleled efforts to effi- 
ciently accommodate IP telephony applications— the 
killer application per se — and with the current work 
focus on a globally scalable infrastructure, H323 is 
well-advanced on its way towards enabling ubiqui- 
tous, interpersonal multimedia communications in an 
integrated global network. 
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